r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

I could use some help determining why the doctests are failing.

I reran the jobs. I think the runner was just flaky.

I'm going to try to find machines resembling the failing platforms that I can test this on.

So is the reason RUSTUP_HOME is needed for some tests is because the rustc that is in the path is the proxy and it needs to look up the actual rustc? Should we do that processing in cargo-test-support and prepend the PATH with the actual one?

So is the reason RUSTUP_HOME is needed for some tests is because the rustc that is in the path is the proxy and it needs to look up the actual rustc? Should we do that processing in cargo-test-support and prepend the PATH with the actual one?

I'm still investigating. I will reply within the next few days.

So is the reason RUSTUP_HOME is needed for some tests is because the rustc that is in the path is the proxy and it needs to look up the actual rustc? Should we do that processing in cargo-test-support and prepend the PATH with the actual one?

That would make sense.

Are you opposed to running rustup entirely? I'm asking because this problem could be solved somewhat easily if one could run rustup which. Would that be acceptable?

As long as it can gracefully work with the absence of rustup

As long as it can gracefully work with the absence of rustup

Rustup's logic for this appears nontrivial: https://github.com/rust-lang/rustup/blob/3382f6f7bf09e591bbda4bcda7daf2280a0061d9/src/cli/rustup_mode.rs#L1033

And clearly, Cargo's tests currently rely on Rustup.

So, if Rustup is not available, is it acceptable to require the user to take additional action, e.g., specify rustc's path in an environment variable?

The only other option I can see is to get rustc's path in a build script, which I assume is still objected to. If no other option seems viable, I have some questions, because I still do not understand the objections to using a build script.

I think there might be a disconnect.

Rustup's logic for this appears nontrivial: https://github.com/rust-lang/rustup/blob/3382f6f7bf09e591bbda4bcda7daf2280a0061d9/src/cli/rustup_mode.rs#L1033

So, if Rustup is not available, is it acceptable to require the user to take additional action, e.g., specify rustc's path in an environment variable?

My thought was that we effectively do sh("rustup which rustc").or(cargo_util::paths::resolve_executable("rustc")), see https://docs.rs/cargo-util/latest/cargo_util/paths/fn.resolve_executable.html

And clearly, Cargo's tests currently rely on Rustup.

Why do you say that? From my understanding it doesn't; I believe we have workarounds for tests that have behavior changes with and without rustup

My thought was that we effectively do sh("rustup which rustc")

I'm with you up to this point.

.or(cargo_util::paths::resolve_executable("rustc")), see https://docs.rs/cargo-util/latest/cargo_util/paths/fn.resolve_executable.html

^ This is the part I am worried about. On my machine, rustc is symlinked to a rustup proxy.

Are you thinking that will only be the case if rustc was installed with rustup?

So, for example, if a user does the following and it fails, it's their problem?

CARGO=$(rustup which cargo)
unset RUSTUP_HOME
$CARGO test

(Sorry if this is a rabbit hole.)